WORLD INTELLECTUAL PROPERTY ORGANIZATION 

International Bureau 




PCX 

INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 



(51) International Patent Classification ^ : 
G07F 7A0 



A2 



(11) International Publication Number: WO 98/52162 

(43) International Publication Date: 19 November 1998 (19.1 1.98) 



(21) International Application Number: PCT/GB98/01402 

(22) International Filing Date: 14 May 1998 (14.05.98) 



(30) Priority Data: 

60/046,514 
60/036,543 
09/023,057 
09/076,551 



15 May 1997 (15.05.97) US 

15 May 1997 (15.05.97) US 

12 February 1998 (12.02.98) US 

12 May 1998 (12.05.98) US 



(71) Applicant: MONDEX INTERNATIONAL LIMITED 

[GB/GB]; 47-53 Cannon Street, London EC4M 5SQ (GB). 

(72) Inventors: EVERETT, David, Barrington; 31 Ashdown Av- 

enue, Saltdean, Brighton, East Sussex BN2 8AH (GB). 
MILLER, Stuart, James; 9 Woodford Green, The War- 
ren, Bracknell, Berks RG12 9YQ (GB). PEACHAM, An- 
thony, David; 4 Lynwood, Groombridge, Tunbridge Wells, 
Kent TN3 9LX (GB). SIMMONS, Ian, Stephens; The 
Elms. School Road, Broughton, Cambs PE17 3AT (GB). 
RICHARDS, Timothy, Philip; 32 Craig Mount, Radlett, 
Herts WD7 7LW (GB). VINER, John, Charles; Hydes, 
Woodlands Lane, Windlesham (GB). 

(74) Agent: POTTER, Julian, Mark; D. Young & Co., 21 New Fetter 
Lane, London EC4A IDA (GB). 



(81) Designated States: AL, AM, AT, AU, AZ, BA, BB, BG, BR, 
BY, CA, CH, CN, CU, CZ, DE, DK, EE, ES, FI, GB, GE, 
GH, GM, GW, HU, ID, IL, IS, JP, KE, KG, KP, KR, ICZ, 
LC, LK, LR, LS, LT, LU, LV, MD, MG, MK, MN, MW, 
MX, NO, NZ, PL, PT, RO, RU, SD, SE, SG, SI, SK, SL, TJ, 
TM, TR, TT, UA, UG, UZ, VN, YU, ZW, ARIPO patent 
(GH, GM, KE, LS, MW, SD, SZ, UG, ZW), Eurasian patent 
(AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), European patent 
(AT. BE, CH, CY, DE. DK, ES, FI, FR. GB. GR, IE, IT, 
LU. MC, NL, PT, SE), OAPI patent (BF, BJ, CF, CG, CI, 
CM. GA, GN, ML. MR, NE, SN, TD. TG). 



Published 

Without international search report and to be republished 
upon receipt of that report. 



(54) Title: SECURE MULTIPLE APPLICATION CARD SYSTEM AND PROCESS 





117 




MANUFACTURER '. 


_S 


CERTIFICATION 






AUTHORITY 




^ ^115 





102 
104 > 



118 



PERSONALIZATION 
BUREAU 



106 



1 



APPLICATION 
LOADER 



CARD ISSUER 




1 116 




111 



10 




CARD 


CARD 




USER 


^ \ 


\ 


107 


109 



(57) Abstract 

A secure multiple application card system and process are provided having secure loading and deleting capability by use of a 
Certification Authority and Personalization Bureau. The certification authority maintains the security of the system by requiring IC cards to 
be injected with its public key and a card identifier for uniquely identifying each card, by providing a personalization data block for each 
card, and by signing with its private key all applications to be loaded or deleted from the IC card. 



BNSDOCID: <WO .. 9852162A2 .1 .> 



FOR THE PURPOSES OF INFORMATION ONLY 



Codes used to identify States party to the PCT on the front pages of pamphlets publishing international applications under the PCX. 



AL 


Albania 


ES 


Spain 


LS 


Lesotho 


SI 


Slovenia 


AM 


Annenia 


FI 


Finland 


LT 


Lithuania 


SK 


Slovakia 


AT 


Austria 


FR 


France 


LU 


Luxembourg 


SN 


Senegal 


AU 


Australia 


GA 


Gabon 


LV 


Latvia 


sz 


Swaziland 


AZ 


Azerbaijan 


GB 


United Kingdom 


MC 


Monaco 


TD 


Chad 


BA 


Bosnia and Herzegovina 


GE 


Georgia 


MD 


Republic of Moldova 


TG 


Togo 


BB 


Barbados 


GH 


Ghana 


MG 


Madagascar 


TJ 


Tajikistan 


BR 


Belgium 


GN 


Guinea 


MK 


The former Yugoslav 


TM 


Turkmenistan 


BF 


Burkina Faso 


GR 


Greece 




Republic of Macedonia 


TR 


IXirkey 


BG 


Bulgaria 


IIU 


Hungary 


ML 


Mali 


TT 


Trinidad and Tobago 


BJ 


Benin 


IE 


Ireland 


MN 


Mongolia 


UA 


Ukraine 


BR 


Brazil 


IL 


Israel 


MR 


Mauritania 


UG 


Uganda 


BY 


Belarus 


IS 


Iceland 


MW 


Malawi 


US 


United States of America 


CA 


Canada 


IT 


Italy 


MX 


Mexico 


UZ 


Uzbekistan 


CF 


Central African Republic 


JP 


Japan 


NE 


Niger 


VN 


Viet Nam 


CG 


Congo 


K£ 


Kenya 


NL 


Netherlands 


YU 


Yugoslavia 


CII 


Switzerland 


KG 


Kyrgyzstan 


NO 


Norway 


ZW 


Zimbabwe 


CI 


C6te d'lvoire 


KP 


Democratic People's 


NZ 


New Zealand 






CM 


Cameroon 




Republic of Korea 


PL 


Poland 






CN 


China 


KR 


Republic of Korea 


PT 


Portugal 






CU 


Cuba 


KZ 


Kazakstan 


RO 


Romania 






CZ 


Czech Republic 


IX 


Saint Lucia 


RU 


Russian Federation 






DE 


Germany 


lA 


Liechtenstein 


SD 


Sudan 






DK 


Denmark 


LK 


Sri Lanka 


SE 


Sweden 






EE 


Estonia 


LR 


Liberia 


SG 


Singapore 







BNSDCX^ID: <WO 9852162A2 I > 



wo 98/52162 



PCT/GB98/01402 



SECURE MULTIPLE APPLICATION CARD SYSTEM AND PROCESS 



-1- 



SUBSTITUTE SHEET (RULE 26) 



BNSDOCID; <WO 9852162A2 I > 



wo 98/52162 



PCT/GB98/01402 



RACKGROUND OF INVENTION 

10 Integrated circuit ("IC) cards are becoming increasingly used for 

many different purposes in the world today. An IC card (also called a smart card) 
typically is the size of a conventional credit card which contains a computer chip 
including a microprocessor, read-only-memory (ROM), electrically erasable 
programmable read-only-memory (EEPROM), an Input/Output (I/O) mechanism 
15 and other circuitry to support the microprocessor in its operations. An IC card may 
contain a single application or may contain multiple independent applications in its 
memory. MULTOS™ is a multiple application operating system which runs on IC 
cards, among other platforms, and allows multiple applications to be executed on 
the card itself. This allows a card user to run many programs stored in the card 
20 (for example, credit/debit, electronic money/purse and/or loyalty applications) 

irrespective of the type of terminal (i.e., ATM, telephone and/or POS) in which the 
card is inserted for use* 

A conventional single application IC card, such as a telephone card 
or an electronic cash card, is loaded with a single application at its personalization 
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stage. That application, however, cannot be modified or changed after the card is 
issued even if the modification is desired by the card user or card issuer. 
Moreover, if a card user wanted a variety of application functions to be performed 
by IC cards issued to him or her, such as both an electronic purse and a credit/debit 

5 function, the card user would be required to carry multiple physical cards on his or 
her person, which would be quite cvimbersome and inconvenient. If an application 
developer or card user desired two different applications to interact or exchange 
data with each other, such as a purse application interacting with a frequent flyer 
loyalty application, the card user would be forced to swap multiple cards in and out 

1 0 of the card-receiving terminal, making the transaction difficult, lengthy and 
inconvenient. 

Therefore, it is beneficial to store multiple applications on the same 
IC card. For example, a card user may have both a purse application and a 
credit/debit application on the same card so that the user could select which type of 
15 payment (by electronic cash or credit card) to use to make a purchase. Multiple 
applications could be provided to an IC card if sufficient memory exists and an 
operating system capable of supporting muhiple applications is present on the card. 
Although multiple applications could be pre-selected and placed in the memory of 
the card during its production stage, it would also be beneficial to have the ability 
20 to load and delete applications for the card post-production as needed. 

The increased flexibility and power of storing multiple applications 
on a single card create new technical challenges to be overcome concerning the 
integrity and security of the information (including application code and associated 
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data) exchanged between the individual card and the application provider as well as 
within the entire system when loading and deleting applications. It would be 
beneficial to have the capability in the IC card system to exchange data among 
cards, card issuers, system operators and application providers securely and to load 
5 and delete applications securely at any time from either a terminal or remotely over 
a telephone line, internet or intranet connection or other data conduit. Because 
these data transmission lines are not typically secure lines, a number of security and 
entity-authentication techniques must be implemented to make sure that applications 
being sent over the transmission lines are only loaded on the intended cards. 
10 As mentioned, it is important - particularly where there is a 

continuing wide availability of new applications to the cardholder — that the system 
has the capability of adding applications onto the IC card subsequent to issuance. 
This is necessary to protect the longevity of the IC cards; otherwise, once an 
application becomes outdated, the card would be useless. In this regard, to protect 
1 5 against the improper or undesired loading of applications onto IC cards, it would be 
beneficial for the IC card system to have the capability of controlling the loading 
process and restricting, when necessary or desirable, the use of certain applications 
to a limited group or number of cards such that the applications are "selectively 
available" to the IC-cards in the system. This "selective capability" would allow 
20 the loading and deleting of applications at, for example, a desired point in time in 
the card's life cycle. It would also allow the loading of an application only to 
those cards chosen to receive the selected application. 

Accordingly, it is an object of embodiments of this invention to 
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provide these important features and specifically an IC-card system having 
improved security that allows for selective availability of smart card applications 
which may be loaded onto IC cards. 

5 SUMMARY OF THE INVENTION 

These and other objectives are achieved by embodiments in 
accordance with the present invention which provide an IC card system comprising 

10 ai least one integrated circuit card and having a certification authority and a 

personalization bureau. The certification authority (''CA'') maintains encryption and 
decryption keys for the entire system and provides the card manufacturer with 
security data to be placed on the card at manufacture. Thus, there is 
advantageously provided a secure multiple application card system. 

15 Specifically, in a preferred embodiment, an IC card is injected at 

manufacture with the public key of the CA and a card identifier for uniquely 
identifying each of the cards. Subsequent to manufacturer, the cards are preferably 
provided to a personalization bureau ("PB") which could be a card issuer, for 
enabling the cards. The PB obtains from the cards the identifiers and forwards a 

20 list of card identifiers to the CA. 

The CA in turn creates a personalization data block for each card 
identifier, and each data block preferably includes card personalization data and an 
individual key set. The data block is encrypted and forwarded back to the PB. By 
using the card identifier, the PB then matches the cards with the encrypted data 
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blocks and separately loads each data block onto the matched card, and preferably 
sets an enablement bit indicating that the card has been enabled and is ready for 
application loading. 

The application loading process is preferably performed at the PB. 
5 At first, the system checks to see whether the card to be loaded is qualified (as 
defined below) to accept the loading of a specific application. The application 
loader via a terminal will be advised if the card is qualified and, if so, a check will 
be done using the CA's public key to determine whether the application to be 
loaded has been signed by the CA's secret key indicating that the application to be 
10 loaded has been allowed by the CA. 



BRIEF DESCRIPTION OF THE DRAWINGS 

15 Further objects, features and advantages of embodiments in 

accordance with the invention will become apparent from the following detailed 
description taken by way of example only and in conjunction with the 
accompanying figures showing illustrative embodiments of the invention, in which 
Fig. 1 is block diagram illustrating the three stages in the life of a 
20 multi-application IC card in a secure system; 

Fig. 2 is a block diagram illustrating the steps of the card 
manufacture process; 

Fig. 3 is a flow diagram illustrating the steps involved in enabling 
each of the IC czirds in the secure system; 
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Fig. 4 is a bloclc diagram of an IC card chip which can be used in 
accordance with the invention; 

Fig. 5 is a block diagram illustrating the data stored on the IC card 
as indicated in block 307 of Fig. 3; 
5 Fig. 5A is a schematic of the data structures residing in an IC card 

and representing personalization data; 

Fig. 6 is a flowchart illustrating the steps of loading an application 
onto an IC card in the secure system; 

Fig. 7 is a flow chart illustrating the checking steps as indicated in 
10 block 601 of Fig. 6; 

Fig. 8 is a flowchart illustrating the steps undertaken in determining 
if loading of an application may proceed; 

Fig. 9 is a block diagram showing the components of the system 
architecture for the enablement process of an IC card in a secure multi-application 
15 IC card system; and 

Fig. 10 is a system diagrsim of entities involved with the use of the 
IC card once it has been personalized. 

Throughout the figures, the same reference numerals and characters, 
unless otherwise stated, are used to denote like features, elements, components or 
20 portions of the illustrated embodiments. Moreover, while the subject invention will 
now be described in detail with reference to the figures, it is done so in cormection 
with the illustrative embodiments. It is intended that changes and modifications can 
be made to the described embodiments without departing from the true scope and 
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spirit of the subject invention as defined by the appended claims. 

DETAILED DESCRIPTION OF THE INVENTION 

5 

An embodiment in accordance with the present invention provides an 
IC card system and process which allow the flexibility to load and delete selected 
applications over the lifetime of a multi-application IC card in response to the needs 
or desires of the card user, card issuers and/or application developers. A card user 
1 0 who has such a card can selectively load and delete applications as desired if 

allowed by the card issuer in conjunction with the system operator or Certification 
Authority ("CA") which controls the loading and deleting process by certifying the 
transfer of information relating to the process. 

By allowing applications to be selectively loaded and deleted from 
15 the card, a card issuer can extend additional functionality to an individual IC card 
without having to issue new cards. Moreover, application developers can replace 
old applications with new enhanced versions, and applications residing on the same 
card using a common multiple application operating system may interact and 
exchange data in a safe and secure manner. For example, a frequent flyer loyalty 
20 program may automatically credit one frequent flyer mile to a card user's internal 
account for every dollar spent with the Mondex purse or with a credit/debit 
application. By allowing the ability to selectively load and delete applications, the 
card user, subject to the requirements of the card issuer, also has the option of 
changing loyalty programs as desired. 
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A card issuer or application developer may intend that a particular 
application be loaded on only one card for a particular card user in a card system. 
A regional bank may desire to have a proprietary application reside only on the 
cards which the bank issues. Embodiments of the present invention would allow 
5 for this selective loading and specifically allow for the prevention of loading 
proprietary applications onto unauthorized cards issued by others. 

To achieve these desired objectives, an embodiment in accordance 
with the present invention gives each card a specific identity by storing "card 
personalization data" on the card. Moreover, each application to be loaded or 
1 0 deleted on one or more cards in the system is assigned "application permissions 
data" which specify the cards upon which the applications may be loaded. 

The type of personalized data can vary depending upon the needs and 
requirements of the card system. In the preferred embodiment, described in greater 
detail below, the personalization data include unique card identification designation 
1 5 data, the card issuer, the product class or type (which is defined by the card issuer) 
and the date of personalization. However, not all of these data elements are 
required to be used and additional elements could also be included. 

The application permissions data associated with an application, also 
described in greater detail below, can be a single value in an identity field or could 
20 include multiple values in the identity field. For example, the application 

permissions data in the card issuer field could represent both product class A and 
product class B from a certain Bank X, indicating that the application could be 
loaded onto cards designated as product classes A and B issued by Bank X (as 

-9- 

SUBSTITUTE SHEET (RULE 26) 

BNSDOCID: < wo.. .... .9852162A2 I > 



wo 98/52162 



PCT/GB98/01402 



indicated in the card product ID field of the card's personalization data). 

In addition, a "global value" could be stored in the issuer field (or 
other field) of the application permissions data indicating that all IC cards in the 
system regardless of who issued the card would match this permissions field. In 
5 this case, for example, a data value of zero stored in the application permissions 
card-issuer field will match all of the cards' personalization card-issuer fields. 

Figure 1 shows the three steps involved in providing an operational 
multi-application IC card in a secure system. The first step is the card 
manufacturing step 101. The second step is the personalization step 103 where card 
10 personalization data (also called entity authentication data) is loaded onto the card. 
The third step is the application loading step 105 which checks to see if a card is 
qualified to receive an application, i.e., when the personalization data is checked 
against the application permissions data associated with the application to be loaded. 
Each of these three steps is described in detail below. 
15 Card Manufacture 

Figure 2 shows the steps necessary in manufacturing an IC card in a 
secure system. Step 201 manufactures the physical IC card by creating the 
integrated circuit on silicon and placing it on the card. The integrated circuit chip 
will include RAM, ROM and EEPROM memories. When the card is first 
20 manufactured, a global public key of the system operator (in this case called the 

Certification Authority (CA)) is stored on each card in ROM in step 203. This will 
allow the card to authenticate that the source of any message to it is from the CA 
since the public key on the card will be matched to the CA's secret key. 
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More specifically, this public key stored on the card will allow the 
individual card to verify data signed with the CA*s private key. The public key of 
the CA, which is stored on the card, is used only for determining if the data sent to 
the card was signed with the proper CA private key. This allows the card to verify 
5 the source of any message coming from the CA. 

Step 205 inserts a card enablement key in a secure portion of 
EEPROM in the card to facilitate card specific confidentiality during enablement, 
and step 207 inserts a card identifier in EEPROM of the card. The identifier, 
which can be accessed by any terminal, will allow the system to determine the 
10 identity of the card in later processes. The identifier is freely available and will not 
be used to authenticate messages. 

Step 209 stores the operating system code in ROM on the card 
including any primitives which are called or supported by the operating system. 
The primitives are written in native language code (e.g., assembly language) and are 
15 stored in ROM. The primitives are subroutines which may be called by the 
operating system or by applications residing on the card such as mathematic 
functions (multiply or divide), data retrieval, data manipulation or cryptographic 
algorithms. The primitives can be executed very quickly because they are written 
in the native language of the processor. After the IC cards are 

20 manufactured, they are sent to a personalization bureau ("PB") to enable and 

personalize the card by storing card personalization data in the memory of the card. 
The terms enablement and personalization are used interchangeably herein to 
indicate the preparatory steps taken to allow the card to be loaded securely with an 
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application. The individual cards are preferably manufactured in batches and are 
sent to a personalization bureau in a group for processing. 

Card Enablement/Personalization 
Figure 3 shows the steps of the card enablement process when the 
5 card arrives at a personalization bureau. The personalization bureau may be the 
card issuer (e.g., a bank or other financial institution) or may be a third party that 
performs the service for the card issuer. The personalization bureau configxires the 
card to a specific user or user class. 

Figure 3 specifically shows the steps taken to enable and personalize 
10 each IC card which will work within the system. The cards can be placed in a 

terminal which communicates with IC cards and which reads the card identifier data 
(previously placed on the card during the manufacturing process — see step 207). 
This card identification data is read from the card in step 301. The terminal will 
effectively send a "get identification data" command to the card and the card will 
1 5 return the identification data to the terminal. 

The PB typically processes a group of cards at the same time, and 
will first compile a list of IC card identification data for the group of cards it is 
personalizing. The PB then sends electronically (or otherwise) this list of 
identification data to the Certification Authority C'CA") which creates a 
20 personalization (or enablement) data block for each card identifier. The data block 
includes the card personalization data organized in a number of identity fields and 
an individual key set for the card, discussed below. These data blocks are then 
encrypted and sent to the PB in step 302. By using the card identification data, the 
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PB then matches the cards with the encrypted data blocks and separately loads each 
data block onto the matched card. To insure that the CA controls the identity of 
the card and the integrity of the system, the PB never obtains knowledge of the 
content of the data blocks transferred. Some aspects of the personalization are 
5 requested by the card issuer to the CA in order to affect their preferred management 
of the cards they issue. The following additional steps are performed. 

Step 303 first checks to see if an enablement bit stored in EEPROM 
of the card has been already set. If it already has been set, the card has already 
been configured and personalized and the enablement process will end as shown in 
10 step 304. A card cannot be enabled and personalized twice. If the bit has not been 
set, then the process continues with step 305. 

In step 305, the individualized card key set for the card being 
enabled (which key set is generated at the CA) is stored on the card. The keys can 
be used later in off-card verification (i.e., to verify that the card is an authentic 
15 card). This verification is necessary to further authenticate the card as the one for 
which the application was intended. 

Step 307 generates four different MULTOS Security Manager 
(MSM) characteristic data elements (otherwise referred to herein as personalization 
data) for the card at the CA which are used for securely and correctly loading and 
20 deleting applications from a particular card. The MSM characteristics also allow 
for the loading of applications on specific classes of identified cards. (These MSM 
characteristics are further described in connection with Figure 5.) 

Other data can also be stored on the card at this time as needed by 
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the system design such as an address table or further subroutines. 

Step 311 sets the enablement bit in EEPROM of the card which 
indicates that the enablement process has been completed for the particular card. 
When this bit is set, another enablement process cannot occur on the card. This 
5 ensures that only one personalization and enablement process will occur to the card 
thus inhibiting illegal tampering of the card or altering the card by mistake. In the 
preferred embodiment, the enablement bit is initially not set when the card is 
manufactured and is set at the end of the enablement process. 

Figure 4 shows an example of a block diagram of an IC card chip 
10 which has been manufactured and personalized. The IC card chip is located on an 
IC card for use. The IC card preferably includes a central processing unit 401, a 
RAM 403, a EEPROM 405, a ROM 407, a timer 409, control logic 41 1, an I/O 
ports 413 and security circuitry 415, which are connected together by a 
conventional data bus. 
15 Control logic 411 in memory cards provides sufficient sequencing 

and switching to handle read- write access to the card's memory through the 
input/output ports. CPU 401 with its control logic can perform calculations, access 
memory locations, modify memory contents, and manage input/output ports. Some 
cards have a coprocessor for handling complex computations like cryptographic 
20 algorithms. Input/output ports 413 are used under the control of a CPU and control 
logic alone, for conununications between the card and a card acceptance device. 
Timer 409 (which generates or provides a clock pulse) drives the control logic 41 1 
and CPU 401 through the sequence of steps that accomplish memory access, 
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memory reading or writing, processing, and data communication. A timer may be 
used to provide application features such as call duration. Security circuitry 415 
includes fusible links that connect the input/output lines to internal circuitry as 
required for testing during manufacture, but which are destroyed ("blown") upon 

5 completion of testing to prevent later access. The personalization data to qualify 
the card is stored in a secured location of EEPROM 405. The comparing of the 
personalization data to applications permissions data is performed by the CPU 401. 

Figure 5 shows the steps of generating and loading the four elements 
of the card personalization data into the memory of the IC cards, and Fig. 5A 

10 shows a schematic of bit maps for each identity field residing in the memory of an 
IC card containing personalization data in accordance with the present invention. 
Each data structure for each identity field has its own descriptor code. Step 501 
loads the data structure for the identity field "card ID" called 

"msm_mcd_j)ermissions_mcd_no.'' This nomenclature stands for MULTOS system 
1 5 manager _ MULTOS card device _ permissions^ MULTOS card device number. 
Although this number is typically 8 bytes long as shown in Fig. 5A, the data could 
be any length that indicates a unique number for the card. In the preferred 
embodiment, 2 bytes are dedicated as a signal indicator, 2 bytes comprise a 
MULTOS Injection Security Module ID (MISM ID) indicating which security 
20 module injected the card with its injected keys when it was manufactured, and 4 
bytes comprise an Integrated Circuit Card (ICC) serial number which identifies the 
individual card produced at the particular MISM. 

Step 503 loads the data structure for the identity field "issuer ID" 
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called "msm__mcd_pennissions_ mcdjssuerjd." This nomenclature stands for a 
MULTOS card device issuer identification number. Each card issuer (such as a 
particular bank, financial institution or other company involved with an application) 
will be assigned a unique number in the card system. Each IC card in the 
5 MULTOS system will contain information regarding the card issuer which 
personalized the card or is responsible for the card. A card issuer will order a 
certain number of cards from a manufacturer and perform or have performed the 
personalization process as described herein. For example, a regional bank may 
order 5,000 cards to be distributed to its customers. The "mcd_issuer_id" data 
10 structure on these cards will indicate which issuer issued the cards. In the preferred 
embodiment, the data structure is 4 bytes long (as shown in Fig. 5A at 503A) to 
allow for many different issuers in the system although the length of the data 
structure can vary with the needs of the card system. 

Step 505 loads the data structure for the identity field "product ID" 
15 called "msm_mcd_permissions_mcd_ issuer jproductjd." This nomenclature stands 
for MULTOS card device issuer product identification number. Each card issuer 
may have different classes of products or cards which it may want to differentiate. 
For example, a bank could issue a regular credit card with one product ID, a gold 
credit card with another product ID and a platinum card with still another product 
20 ID. The card issuer may wish to load certain applications onto only one class of 
credit cards. A gold credit card user who pays an annual fee may be entitled to a 
greater variety of applications than a regular credit card user who pays no annual 
fee. The product ID field identifies the card as a particular class and will later 
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allow the card issuer to check the product ID and only load applications onto cards 
which match the desired class. 

Another way to differentiate products is by application type, such as 
by categorizing the application as financial, legal, medical and/or recreational, or by 
5 assigning particular applications to a group of cards. For example, one card issuer 
may have different loyalty programs available with different companies to different 
sets of card users. For example, a bank may have an American Airlines® loyalty 
program and a British Airways® loyalty program for different regions of the 
country dependent on where the airlines fly. The product type allows the issuer to 
1 0 fix the product classification of the card during the personalization process. When 
loading applications onto the card, the product type identification number on each 
card will be checked to make sure it matches the type of card onto which the issuer 
desires to load. The product type data structure is preferably an indexing 
mechanism (unlike the other personalization data structure) of 8 bits (as shown at 
1 5 505A in Fig. 5A) but could be any length depending upon the needs of the card 
system. In the illustrated embodiment, the resulting instruction would be to locate 
the second bit (since the byte's indicated value is 2) in the array to be searched 
(see discussion of step 809 below). 

Step 507 loads the data structure for the identity field data called 
20 ''msm_mcd_permissions_mcd_ controls_data_ date." This nomenclature stands for 
the MULTOS card device controls data date or, in other words, the date on which 
the card was personalized so that, for example, the application loader can load cards 
dated only after a certain date, load cards before a certain date (e.g., for application 
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updates) or load cards with a particular data date. The information can include the 
year, month and day of personalization or may include less information, if desired. 
The data__date data structure is preferably 1 byte in length (see 507A in Fig. 5A) 
although it could be any length depending upon the needs of the particular card 
5 system used. 

Once all of the personalization data structures are loaded and stored 
in the card, the card has been identified by issuer, product class, date and 
identification number (and other data fields, if desired), and the card cannot change 
its identity; these fields cannot be changed in the memory of the card. If a card 
1 0 user wants to change the product id stored in the card to gain access to different 
applications available to another product type, a new card will have to be issued to 
the user containing the correct personalization data. This system is consistent with 
a gold card member receiving a new card when the classification is changed to 
platinum. 

1 5 After the card has been enabled and personalized by storing its 

individual card key set, MSM personalization characteristics and enablement bit as 
described in Fig. 3, the card is ready to have applications loaded into its memory. 

Loading Applications 
The application loading process contains a number of security and 
20 card configuration checks to ensure the secure and proper loading of an application 
onto the intended IC card. The application loading process is preferably performed 
at the personalization bureau so that the card will contain one or more applications 
when the card is issued. The card may contain certain common applications which 
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will be present on every card the issuer sends out, such as an electronic purse 
application or a credit/debit application. Alternatively, the personalization bureau 
could send the enabled cards to a third party for the process of loading applications. 
The multiple application operating system stored in the ROM of each card and the 
5 card MSM personalization data is designed to allow futxire loading and deleting of 
applications after the card has been issued depending upon the desires of the 
particular card user and the responsible card issuer. Thus, an older version of an 
application stored on the IC card could be replaced with a new version of the 
application. An additional loyalty application could also be added to the card after 
10 it has been initially sent to the card user because the application is newly available 
or the user desires to use the new application. These loading and deleting functions 
for applications can be performed directly by a terminal or may be performed over 
telephone lines, data lines, a network such as the Internet or any other way of 
transmitting data between two entities. In the present IC card system, the process 
15 of transmitting the application program and data ensures that only IC cards 

containing the proper personalization data and which fit on application permissions 
profile will be qualified and receive the corresponding application program and 
data. 

Figure 6 shows the preferred steps performed in loading an 
20 application onto an IC card in the MULTOS IC card system. For this example, the 
personalization bureau is loading an application from a terminal which enabled the 
same card. Step 601 performs an "open command" initiated by the terminal which 
previews the card to make sure the card is qualified to accept the loading of a 
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specific application. The open command provides the card with the application's 
permissions data, the application's size, and instructs the card to determine (1) if 
the enablement bit is set indicating the card has been personalized; (2) whether the 
application code and associated data will fit in the existing memory space on the 
5 card; and (3) whether the personalization data assigned to the application to be 
loaded allows for the loading of the application onto the particular card at issue. 
The open command could also make additional checks as required by the card 
system. These checking steps during the open command execution will be 
described in detail in conjunction with Figure 7. 
10 After the open command has been executed, the application loader 

via the terminal will be advised if the card contains the proper identification 
personalization data and if enough room exists in the memory of the card for the 
application code and related data. If there is insufficient memory, then a negative 
response is returned by the card and the process is abended (abnormally ended). If 
1 5 the identification personalization data does not match the applications permissions 
data, a warning response is given in step 603, but the process continues to the load 
and create steps. Alternatively, if there is no match, the process may automatically 
be abended. If a positive response is returned by the card to the terminal in step 
605, the application loader preferably proceeds to next steps. The open command 
20 allows the application to preview the card before starting any transfer of the code 
and data. 

Step 607 then loads the application code and data onto the IC card 
into EEPROM. The actual loading occurs in conjunction with create step 609 
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which completes the loading process and enables the application to execute on the 
IC card after it is loaded. The combination of the open, load and create commands 
are sent by the terminal, or another application provider source, to the IC card to 
perform the application loading process. The operating system in the IC cards is 
5 programmed to perform a specific set of instructions with respect to each of these 
commands so that the IC card will communicate with and properly carry out the 
instructions from the terminal. 

Step 609 performs the create command which at least: ( 1 ) checks if 
an application load certificate is signed (encrypted) by the CA and therefore 
10 authenticates the application as a proper application for the system; and (2) checks 
the card personalization data stored on the card against the permissions profile for 
the application to be loaded to qualify the card for loading. It may do other checks 
as required. If one of the checks fails, then a failure response 610 is given and the 
process aborts. The application after it has passed these checks will be loaded into 
1 5 the memory of the card. 

Figure 7 shows the various steps of the open step 601 of Fig. 6 in 
more detail. Step 701 determines if the enablement (i.e., control) bit is set. This 
bit is set when the card has completed its personalization process and has been 
assigned its personalization data. An application can be loaded on an I C card in the 
20 card system only if the card contains the personalization data. If the enablement bit 
is not set, the card has not been personalized and therefore the card returns a 
negative response 703 to the terminal. If the enablement bit is set, then the card 
has been enabled and the test conditions continue with step 711. 
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Step 711 checks if there is sufficient space in the memory on the 
card to store the application code and its associated data. Applications will 
typically have associated data related to their functions. This data will be used and 
manipulated when the application is run. Storage space in the memory of an IC 

5 card is a continuing concern due to the relatively large physical space required for 
EEPROM and how it fits in the integrated circuit which is desired to be small 
enough to fit on a credit card sized card. An example of the size of a preset 
EEPROM on an IC card is 16K bytes although the actual size varies. Applications 
can range from 1 K byte or less for a very simple application up to the size of 

10 available memory for a more sophisticated application. The data associated with an 
application can range from no data being stored in the card memory to a size 
constrained by the amount of available memory. These varied sizes of application 
code and data continually increase as applications become more advanced and 
diverse. 

1 5 MULTOS as an operating system is not limited by the number of 

applications and associated data it can store on the card. Thus, if five applications 
can fit in the available memory of the card, the card user will have greatly 
increased functionality than if one or two applications were stored on the card. 
Once a card*s memory is filled to its capacity, however, a new application cannot 

20 be loaded onto the card unless another application including its code and data of 
sufficient size can be deleted. Therefore, checking the amount of available space 
on the card is an important step. If there is not sufficient space, then an insufficient 
space response 713 will be returned to the terminal. The application loader can 
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then decide if another existing application on the card should be deleted to make 
room for the new application. Deletion depends upon the card issuer having an 
application delete certificate from the CA, If there is sufficient space on the card, 
then the process continues with step 715. 
5 An example of the testing of memory spaces in step 71 1 is now 

described. The numbers used in this example in no way limit the scope of the 
invention but are used only to illustrate memory space requirements. An IC card 
may have 1 6K available EEPROM when it is first manufactured. The operating 
system data necessary for the operating system may take up 2K of memory space. 
10 Thus, 14K would remain. An electronic purse application's code is stored in 

EEPROM and may take up 8K of memory space. The purse application's required 
data may take up an additional 4K of memory space in EEPROM. The memory 
space which is free for other applications would thus be 2K (16K-2K-8K-4K=2K). 
If a card issuer wants to load a credit/debit application whose code is 6K bytes in 
1 5 size onto the card in this example, the application will not fit in the memory of the 
IC card. Therefore, the application caimot load the new application without first 
removing the purse application from the card. If a new credit/debit application was 
loaded into EEPROM of the IC card, then it would have to overwrite other 
application's code or data. The application loader is prevented from doing this. 
20 Figure 8 shows the steps performed in determining whether the 

card's personalization data falls within the permissible set of cards onto which the 
application at issue may be loaded. These steps are preferably performed during the 
execution of the "create" conunand. However, these steps may be performed at any 
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time during the loading or deleting of an application. As described previously, the 
card is personalized by storing data specific to the card (MSM personalization data) 
including: a card ID designation specific to an individual card, the card issuer 
number indicating the issuer of the card, the product type of the card, such as a 
5 gold or platinum card, and the date the card was personalized. This data uniquely 
identifies the card apart from all other IC cards in the system. 

Accordingly, applications can be selectively stored on individual 
cards in the IC card system on virtually any basis, including the following. An 
application can be loaded selectively to cards containing one or more specific card 
10 numbers. An application can be selectively loaded on one or more cards containing 
a specified card issuer ID. Moreover, an application can be loaded only upon one 
type of product specified by the particular card issuer, and/or the application can be 
loaded only on cards which have a specified date or series of dates of 
personalization. Each of the personalization data allows an application to be 
1 5 selectively loaded onto certain cards or groups of cards and also ensures that cards 
without the proper permissions will not receive the application. Personalization 
data types in addition to the four described can also be used as needed. 

The selection of IC cards upon which a particular application may be 
loaded is made possible by the use of "applications permissions data" which is 
20 assigned to the application and represents at least one set of cards upon which the 
application may be loaded. The set may be based on virtually any factor, including 
one or more of the following: card numbers, card issuers, product types or 
personalization dates. Although the individual card's personalization data typically 
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identify one specific number, one card issuer, one product type and one date, the 
application's permissions data may indicate a card number or a blanket permission, 
a card issuer or a blanket permission, and a number of product types and dates. 

For example, a frequent loyalty program may be configured to allow 
5 its loading and use on cards in different product classes belonging to one card 
issuer. In addition, the application permissions data may indicate that the loyalty 
program can be used on gold and platinum product types if the card was issued 
after May, 1998. Thus, the MSM permissions check will determine if the card's 
individual personalization data is included in the allowed or permissible set of cards 
10 upon which the application may be loaded. If it is, the application will be loaded. 

To expedite the comparison process, an alternative embodiment may 
include setting one or more permissions data at zero representing a blanket 
permission for that particular data. For instance, by placing a zero for the "card 
number" entry in the application permissions data or some other value indicating 
1 5 that all cards may be loaded regardless of their number, the system knows not to 
deny any cards based on their card number. Moreover, if a zero is placed in the 
application's permissions data "issuer ID," then all cards similarly will pass the 
"issuer" test comparison. This feature allows greater flexibility in selecting groups 
of cards. The zero indicator could also be used for other permissions data, as 
20 required. 

Referring to Figure 8, each of the permissions data is checked in the 
order shown, but other orders could be followed because if any one of the 
permissions fails, the application will be prevented from being loaded on the IC 
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card being checked. The permissions are preferably checked in the order shown. 
Step 801 checks if the application permissions product type set encompasses the 
card's product type number stored in the memory of the card. Each card product 
type is assigned a number by the system operator. The product types are specified 
5 for each card issuer because different card issuers will have different product types. 
The cards are selectively checked to ensure that applications are loaded only on 
cards of authorized product type. The application permissions product type set can 
be 32 bytes long which includes multiple acceptable product types or can be a 
different length depending upon the needs of the system. Using data structure 505A 
10 as an example, the operating system would check bit number 2 in the 256 bit array 
(32 bytes x 8 bits per byte) resulting from the 32 byte long application permissions 
data structure. If the permissions check fails, then the card returns a failure 
message to the terminal in step 803. If the product type check passes (for example, 
the value of bit no. 2 being 1), then the process continues with step 805. 
1 5 Step 805 checks if the application permissions allowable card issuer 

number set encompasses the card's issuer number stored in the memory of the card 
or if the application permissions issuer data is zero (indicating all cards pass this 
individual permissions check). Each card issuer is assigned a number by the system 
operator and the cards are selectively checked to ensure that applications are loaded 
20 only on cards distributed by authorized card issuers. The application permissions 
card issuer number set can be 4 bytes long if one issuer is designated or can be 
longer depending upon the needs of the system. If the issuer check fails, then the 
card returns a failure message to the terminal in step 807. If the check passes, then 
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the process continues with step 809. 

Step 809 checks if the application permissions date set encompasses 
the card's data date stored in the memory of the card. The date that the IC card 
was personalized will be stored and will preferably include at least the month and 

5 year. The cards are selectively checked to ensure that applications are loaded only 
on cards with the authorized personalization date. The application permissions date 
set can be 32 bytes long which includes multiple dates or can be a different length 
depending upon the needs of the system. If the date permissions check fails, then 
the card returns a failure message to the terminal in step 811. If the date check 

10 passes, then the process continues with step 813. 

Step 8 1 3 checks if the application permissions allowable card number 
set encompasses the card's ID number stored in the card memory or if the 
application permissions allowable card number data is zero (indicating all cards pass 
this individual permissions check). The testing of the permissions is performed on 

1 5 the card during the execution of the open, load and create commands. The 

application permissions card number data set can be 8 bytes long if one number is 
designated or can be longer depending upon the needs of the system. If the card 
number check fails, then the card returns a failure message to the terminal in step 
815. If the check passes, then the process continues with step 817. 

20 

Summary of IC Card System's Process 
Figure 9 shows the components of the system architecture for the 
card initialization process of an IC card in a secure multiple application IC card 
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system. The system includes a card manufacturer 102, a personalization bureau 
104, an application loader 106, the IC card 107 being initialized, the card user 109 
and the certification authority 111 for the entire multiple application secure system. 
The card user 131 is the person or entity who will use the stored applications on the 
5 IC card. For example, a card user may prefer an IC card that contains both an 
electronic purse containing electronic cash (such as MONDEX^^) and a credit/debit 
application (such as the MasterCard® EMV application) on the same IC card. The 
following is a description of one way in which the card user would obtain an IC 
card containing the desired applications in a secure manner. 
10 The card user would contact a card issuer 113, such as a bank which 

distributes IC cards, and request an IC card with the two applications both residing 
in memory of a single IC card. The integrated circuit chip for the IC card would 
be manufactured by manufacturer 102 and sent to the card issuer 113 (or an entity 
acting on its behalf) in the form of an IC chip on a card. As discussed above (see 
15 steps 201-209), during the manufacturing process, data is transmitted 115 via a data 
conduit from the manufacturer 102 to card 107 and stored in IC card 107's 
memory. (Any of the data conduits described in this figure could be a telephone 
line, Internet connection or any other transmission medium.) The certification 
authority 111, which maintains encryption/decryption keys for the entire system, 
20 transmits 1 17 security data (i.e., global public key) to the manufacturer over a data 
conduit which is placed on the card by the manufacturer along with other data, such 
as the card enablement key and card identifier. The card's multiple application 
operating system is also stored in ROM and placed on the card by the manufacturer. 
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After the cards have been initially processed, they are sent to the card issuer for 
personalization and application loading. 

The card issuer 1 13 performs, or has performed by another entity, 
two separate functions. First, the personalization bureau 104 personalizes the IC 
5 card 107 in the ways described above, and second, the application loader 106 loads 
the application provided the card is qualified, as described. 

Regarding personalization, an individualized card key set is generated 
by the CA and stored on the card (see Fig. 3). The card is further given a specific 
identity using MSM personalization (see Fig. 3, step 307 and Fig. 5) including a 
10 card ID number, an issuer ID number identifying the card issuer which processed 
the card, a card product type number which is specified by the card issuer and the 
date upon which the personalization took place. After the card has been 
personalized, applications need to be loaded onto the card so that the card can 
perform desired functions. 
15 The application loader 106, which could use the same terminal or 

data conduit as personalization bureau 104, first needs to have determined if the 
card is qualified to accept the application. This comparison process takes place on 
the card itself (as instructed by its operating system) using the permissions 
information. The card, if it is qualified, thus selectively loads the application onto 
20 itself based upon the card*s identity £ind the card issuer's instructions. The 

application loader communicates 1 19 with the IC card via a terminal or by some 
other data conduit. After the applications have been loaded on the card, the card is 
delivered to the card user 109 for use. 
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The secure multiple application IC card system described herein 
allows for selective loading and deleting of applications at any point in the life 
cycle of the IC card after the card has been personalized. Thus, a card user could 
also receive a personalized card with no applications and then select a desired 
5 application over a common transmission line such as a telephone line or Internet 
connection. 

Figure 10 is a system diagram of entities involved with the use of an 
IC card once it has been personalized. The system includes an IC card 151, a 
terminal 153, an application load/delete entity 155, the certification authority 157, a 
10 card issuer 171 and other IC cards 159 in the system. The arrows indicate 

communication between the respective entities. The C A 1 57 facilitates loading and 
deleting of applications. After providing the MSM permissions data and card 
specific keyset to the card during card enablements, the CA allows applications to 
be later loaded and deleted preferably by issuing an application certificate. 
1 5 Application specific keys are required to authenticate communication between a 

card and terminal. The IC card 151 also can communicate with other IC cards 159. 
Card issuer 171 is involved with all decisions of loading and deleting applications 
for a card which it issued. All communications are authenticated and transmitted 
securely in the system. 
20 For instance, IC card 151 will use the following procedure to load a 

new application onto the card. IC card 101 is connected to terminal 153 and the 
terminal requests that an application be loaded. Terminal 153 contacts application 
load/delete entity 155 which, as a result and in conjunction with card issuer 171, 
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sends the application code, data and application permissions data (along with any 
other necessary data) to terminal 153, Terminal 153 then queries card 151 to 
ensure it is the correct card onto which the application may be loaded. If IC card 
passes the checks discussed above, the application is loaded onto card 151. The CA 
5 157 provides the application load or delete certificate that enables the application to 
be loaded or deleted from the card. This example shows one way to load the 
application, but other variations using the same principles could be performed, such 
as directly loading the application at the application load/delete entity 155. 

The foregoing merely illustrates the principles of the invention. It 
10 will thus be appreciated that those skilled in the art will be able to devise numerous 
systems and methods which, although not explicitly shown or described herein, 
embody the principles of the invention and are thus within the spirit and scope of 
the invention. 

For example, it will be appreciated that the MSM personalization and 
1 5 permissions data may not only be used for loading applications onto IC cards but 
also for deleting applications from said cards. The same checks involving MSM 
permissions and loading applications are made for deleting applications. A delete 
certificate from the CA authorizing the deletion of an application will control from 
which cards the application may be deleted. This is accomplished through the 
20 personalization data stored on each IC card and the permissions check as described 
herein. 

Moreover, the data may also be applicable to personal computers or 
other units onto which applications may be loaded which are not physically loaded 
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on cards. In addition, the application's permissions data may actually include data 
representative of a set or sets of cards to be excluded, instead of included ~ cards 
that cannot be loaded with the application. 

The scope of the present disclosure includes any novel feature or 
5 combination of features disclosed therein either explicitly or implicitly or any 
generalisation thereof irrespective of whether or not it relates to the claimed 
invention or mitigates any or all of the problems addressed by the present invention. 
The application hereby gives notice that new claims may be formulated to such 
features during the prosecution of this application or of any such further application 
10 derived therefrom. In particular, with reference to the appended claims, features 
from dependant claims may be combined with those of the independent claims in 
any appropriate manner and not merely in the specific combinations enumerated in 
the claims. 



-32- 



BNSDOCID: <WO 9852162A2 I > 



SUBSTITUTE SHEET (RULE 26) 



wo 98/52162 



PCT/GB98/01402 



mi f\ mmm^ 

ANNEX A 

MULTI-APPLICATION IC CARD SYSTEM 
Integrated circuit ("ICT) cards are becommg increasmgly used for many 
different purposes in the world today. An IC card (also called a smart card) typically is 
the size of a conventional credit card which contains a computer chip including a 
microprocessor, read-only-memory (ROM), electrically erasable programmable read- 
only-memory (EEPROM), an Iiqjut/Output (I/O) mechanism and otiier circuitry to 
support the microprocessor in its operations. An IC card may contain a single application 
or may contain multiple independent applications in its memory. MULTOS™ is a 
multiple application operating system which runs on IC cards, among other platforms, 
and allows multiple applications to be executed on the card itself! This allows a card user 
to run many programs stored in the card (for example, credit/debit, electronic 
money/purse and/or loyalty applications) irrespective of the type of terminal (i.e., ATM, 
telephone and/or POS) in which the card is inserted for use. 

A conventional single application IC card, such as a telephone card or an 
electronic cash card, is loaded with a single iqjplication at its personalization stage. That 
application, however, cannot be modified or changed after the card is issued even if the 
modification is desired by the card user or card issuer. Moreover, if a card user wanted a 
variety of application fimctions to be perfoimed by IC cards issued to him or her, such as 
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AiEX A TOlH^OMiPllON 



both an electronic purse and a credit/debit function, the card user would be required to 
carry multiple physical cards on his or her person, which would be quite cumbersome and 
inconvenient If an appUcation developer or card user desired two different appUcations 
to interact or exchange data with each other, such as a purse appUcation interacting with a 
ftequent flyer loyalty appUcation. the card user would be forced to swap multiple cards in 
and out of the card-receiving terminal, making the transaction difficult, lengthy and 
inconvemenL 

TTie AppUcant has recognised therefore, that it is beneficial to store multq,le 

appHcations on the same IC .aid. For example, a card user may have both a purse 

appUcation and a credit/debit appUcation on the same card so that the user could select 

yMch type of payment (by electronic cash or credh card) to use to make a purchase. 

Mul^le appUcations could be provided to an IC card if sufScient memory exists and 

an operating system capable of supporting multiple appUcations is present on the card. 

Although multiple appUcations could be pre-selected and placed m the memory of the 

card dming is production stage, it would also be beneficial to have the abiUty to load 

and delete appUcations for card post-production as needed. 

The increased flexibility and power of storing multiple appUcations on a 

single card createnew challenges to be overcome concerning the integrity and security of 

the information (including appUcation code and associated data) exchanged between the 

individual card and the appUcation provider as weU as witfam the entire system when 
loading and deleting appUcations. ITie AppUcant has fiiither recognised that it 

wouH be beneficial to have the capability of the IC 

^^U> c«tans= dau among cards, card issuers, system cp«a»rs and apphcanon 



BNSDOCID: <WO _ . 9852162A2 I > 



SUBSTITUTE SHEET (RULE 26) 



wo 98/52162 PCT/GB98/0I402 



m a loiiiiPiit 



providers securely and to load and delete applications securely at any time ftom either a 
terminal or remotely over a telephone line, internet or intranet connection or other data 
conduit. Because these data transmission lines are not typically secure Imes, a number of 
security and entity-authentication techniques must be implemented to make sure that 
appUcations being sent over the transmission lines are only loaded on the intended cards. 

As mentioned, it is important - particularly where there is a continuing 
wide availabiUty of new applications to the cardholder - that the system has the 
capabiUty of adding applications onto the IC card subsequent to issuance. This is 
highly advantageous since it protects the longevity of the IC cards; otherwise, once an 
appHcation becomes outdated, the card would be useless. In this regard, to protect 
against the improper or undesired loading of appUcations onto IC cards, the 
Applicant has fiuther recognised that it would be beneficial for the IC card 
system to have the capability of controlling the loading process and restricting, when 

necessary or desirable, the use of certain applications to a limited group or number of 

cards such that the applications are "selectively available" to the IC-cards in the system. 

This "selective capability" would allow the loading and deleting of applications at, for 

example, a desired point in time in the card's life cycle. It would also allow the loading 

of an appUcation only to tliose cards chosen to receive the selected application. 

Accordingly, it is an advantage of a preferred embodiment of the invention that 

it provides these inq)ortant features and spedfically a secure IC-card system that 
allows for selective availability of smart card applications which may be loaded onto IC 
cards. 
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These and other advantages are achieved by an embodiment 
of the present invention w^ch proves an IC card system con^iising 
at least one IC card and an application to be loaded onto the card 
wherein the IC card contains card personalization date and the 

application is assigned application pennissions data designating which IC card or group 
of IC cards upon which the application may be loaded. The system checks to determine 
whether the card's personalization data falls withm the permissible set indicated by the 
application's permissions data. If it does, the application may be loaded onto the card. 

In a preferred embodiment, the card personalization data is transferred 
onto the card by the personalization bureau after the card is manufactured. The data 
preferably includes data representing the card number, the issuer, product class (i.e., such 
as gold or platiniun cards), and the date on which the card was personalized. The card 
further preferably contains enablement data indicating whether or not the card has been 
enabled with personalized data. 

In a further preferred embodiment, the IC card secure system checks the 
enablement data prior to loading an application to determine whether or not the card has 
been enabled. Preferably, if the card has been enabled, the system checks if the card 
number, the issuer, the product class and/or the date on which the card was personalized 
are within the acceptable set indicated by the application's pennissions data. If so, the 
application may be loaded onto the IC card. 
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In yet another preferred embodiment, the appUcation's permissions data 
may contain data representative of a blanket pemiission such that all cards would pass for 

application loading. 

Further aspects, features and advantages of embodiments of the imrention witt 

become apparent fromthe following detafled description taken in conjmiction wMi tixe 
accompanying figures showing iUustrative embodiments of the invention, m which 

Fig. 1 is block diagram illustrating the three stages in the life ofamulti- 

application IC card in a secure system; 

Fig. 2 is a block diagram illustrating the steps of the card manufacture 

process; 

Fig. 3 is a flow diagram illustrating the steps involved in enabling each of 

the IC cards in the secure system; 

Fig. 4 is a block diagram of an IC card chip which can be used in 
accordance with an embodiment of the invention; 

Fig. 5 is a block diagram illustrating the data stored on the IC card as 

indicated in block 307 of Fig. 3; 

Fig. 5A is a schematic of the data structures residing in an IC card and 

representing personalization data; 
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Fig. 6 is a flowchart illustrating the steps of loading an application onto an 

IC card in the secure system; 

Fig. 7 is a flow chart illustrating the checking steps as indicated in block 

601 of Fig. 6; 

5 Fig. 8 is a flowchart illustrating the steps undertaken in determining if 

loading of an application may proceed; 

Fig. 9 is a block diagram showing the components of the system 
architecture for the enablement process of an IC card in a secure multi-appUcation IC 
card system; and 

10 Fig. 10 is a system diagram of entities involved with the use of the IC card 

once it has been personalized. 

Throughout the figures, the same reference numerals and characters, 
unless otherwise stated, are used to denote like features, elements, components or 
portions of the illustrated embodiments. Moreover, while the subject invention will now 

15 be described in detail with reference to the figures, it is done so in connection with the 
illustrative embodiments. It is intended that changes and modifications can be made to 
the described embodiments without departing fi-om the true scope and spirit of the subject 
invention as defined by the appended claims. 
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An embodimeot of the present invention provides an IC card ^stem and 
process which allow the flexibility to load and delete selected applications over the 
lifetime of a multi- application IC card in response to the needs or desires of the card 
user, card issuers and/or application developers. A card user v/ho has sudi a card can 
selectively load and delete applications as desired if allowed by the card issuer in 
conjunction with the system operator or Certification Authority (*'CA") yiMsh controls 
the loadmg and deleting process by certifying the transfer of mformation relating to the 
process. 

By allowing appUcations to be selectively loaded and deleted from the 
card, a card issuer can extend additional functionality to an individual IC card without 
having to issue new cards. Moreover, appUcation developers can replace old appUcations 
witii new enhanced versions, and applications residing on the same card using a common 
multiple appUcation operating system may mteract and exchange data in a safe and secure 
manner. For example, a frequent flyer loyalty program may automaticaUy credit one 
frequent flyer mile to a card user's mtemal account for every doDar 
speat with an electronic purse such as the 

Mondex purse or witii a credit/debit application. By aUowing the abiUty to selectively 
load and delete applications, the card user, subject to the requirements of the card issuer, 
also has the option of changing loyalty programs as desired. 

A card issuer or application developer may intend that a particular 
appUcation be loaded on only one card for a particular card user in a card system. A 
regional bank may desire to have a proprietary application reside only on the cards which 
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the bank issues. Enibodmients in accordance with the present invention would allow 
for this selective loading and specifically allow for the prevention of loading 
proprietary applications onto unauthorized cards issued by others. 

To achieve these desired objectives, embodiments of the present invention give 
each card a specific indentity by storing "card personalization data" on the card. 
Morover, each appUcation to be loaded or deleted on one or more cards m the system 
is assigned "application permissions data" which specify the cards upon which the 
appUcations may be loaded. 

The type of personalized data can vary depending upon the needs and 
requirements of the card system. In the preferred embodiment, described in greater detail 
below, the personalization data include unique card identification designation data, the 
card issuer, the product class or type (which is defined by the card issuer) and the date of 
personalization. However, not all of these data elements are required to be used and 
additional elements could also be included. 

The application pennissions data associated Avith an application, also 
described in greater detail below, can be a single value in an identity field or could 
include multiple values in the identity field. For example, the application permissions 
data in the card issuer field could represent both product class A and product class B from 
a certain Bank X, mdicating that the application could be loaded onto cards designated as 
product classes A and B issued by Bank X (as indicated in the card product ID field of the 
card*s personalization data). 
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In addition, a "global value" could be stored in the issuer field (or other 
field) of the application permissions data indicating that all IC cards in the system 
regardless of who issued the card would match this pennissions field. In this case, for 
example, a data value of zero stored in the application pennissions card-issuer field will 

5 match all of the cards' personalization card-issuer fields. 

Figure 1 shows the three steps involved in providing an operational multi- 
application IC card in a secure system. The first step is the card manufacturing step 101. 
The second step is the personalization step 103 where card personalization data (also 
called entity authentication data) is loaded onto the card. The third step is the application 

1 0 loading step 1 05 which checks to see if a card is qualified to receive an application, i.e., 
when the personalization data is checked against the application pennissions data 
associated with the application to be loaded. Each of these three steps is described in 
detail below. 

ra^ Manufacture 

15 Figure 2 shows the steps necessary in manufacturing an IC card in a secure 

system. Step 201 manufactures the physical IC card by creating the integrated circuit on 
silicon and placing it on the card. The integrated circuit chip will include RAM, ROM 
and EEPROM memories. When the card is first manufacttired, a global public key of the 
system operator (in this case called the Certification Authority (CA)) is stored on each 

20 card m ROM in step 203. This will allow the card to authenticate that the source of any 
message to it is from the CA since the public key on the card will be matched to the CA's 
secret key. 
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More specifically, this public key stored on the card will allow the 
individual card to verify data signed with the CA's private key. The pubUc key of the 
CA, which is stored on the card, is used only for determining if the data sent to the card 
was signed with the proper CA private key. This allows the card to verify the source of 
5 any message coming from the CA. 

Step 205 inserts a card enablement key in a secure portion of EEPROM in 
the card to facilitate card specific confidentiality during enablement, and step 207 mserts 
a card identifier in EEPROM of the card. The identifier, which can be accessed by any 
teraiinal, will allow the system to deiemiine the identity of the card in later processes. 
1 0 The identifier is freely available and will not be used to authenticate messages. 

Step 209 stores the operating system code in ROM on the card including 
any primitives which are called or supported by the operating system. The primitives are 
wrinen in native language code (e.g., assembly language) and are stored in ROM. The 
primitives are subroutines which may be called by the operating system or by 
1 5 applications residmg on the card such as mathematic fimctions (multiply or divide), data 
retrieval, data manipulation or cryptographic algorithms. The primitives can be executed 
very quickly because they are written in the native language of the processor. 

After the IC cards are manufacmred, they are sent to a personalization bureau 
("PB") to enable and personalize the card by storing card personalization data in the 
20 memory of the card. The terms enablement and personalization are used interchangeably 
herein to indicate the preparatory steps taken to allow the card to be loaded securely with 
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an application. The individual cards arc preferably manufactured in batches and are sent 
to a personalization bureau in a group for processing. 

rnri T-r''W""g"t/Prr;oTiaii7atipn 
Figure 3 shows the steps of the card enablement process when the card 
5 arrives at a personalization bureau. The personalization bureau may be the card issuer 
(e.g., a bank or other financial institution) or may be a third party that performs the 
service for the card issuer. The personalization bureau configures the card to a specific 
user or user class. 

Figure 3 specifically shows the steps taken to enable and personalize each 
10 IC card which will work widrin the system. The cards can be placed in a terminal which 
communicates with IC cards and which reads the card identifier data (previously placed 
on the card during the manufacmring process - see step 207). Tlus card identification 
data is read from the card in step 301. The tenninal will effectively send a "get 
identification data" command to die card and the card will return the identification data to 
IS the terminaL 

The PB typically processes a group of cards at the same time, and will first 
compile a list of IC card identification data for die group of cards it is personalizing. The 
PB then sends electronically (or otherwise) this Ust of identification data to die 
Certification Autiiority ("CA^O which creates a personalization (or enablement) data 
20 block for each card identifier. The data block includes die card personalization data 

organized in a number of identity fields and an individual key set for the card, discussed 
below. These data blocks are tfien encrypted and sent to die PB in step 302. By using die 
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card identification data, the PB then matches the cards with the encrypted data blocks and 
separately loads each data block onto the matched card. To insure that the CA controls 
the identity of the card and die integrity of the system, the PB never obtains knowledge of 
the content of die data blocks transferred. Some aspects of the personalization are 
5 requested by the card issuer to the CA in order to affect dieir preferred management of 
die cards they issue. The following additional steps are perfiMmed. 

Step 303 first checks to see if an enablement bit stored in EEPROM of the 
card has been already set. If it already has been set, die card has already been configured 
and personalized and die enablement process will end as shown in step 304. A card 
10 cannot be enabled and personalized twice. If die bit has not been set, dien die process 

continues with step 305. 

In step 305, the individualized card key set for die card being enabled 
(which key set is generated at die CA) is stored on die card. The keys can be used later in 
off-card verification (i.e., to verify diat die card is an audientic card). This verification is 
1 5 necessary to fiirther audienticate die card as die one for which die application was 
intended. 

Step 307 generates four difEerent MULTOS Security Manager (MSM) 
characteristic data elements (odierwise referred to herem as personalization data) for die 
card at die CA which are used for securely and correctly loading and deleting applications 
20 from a particular card. The MSM characteristics also allow for die loadmg of 

appUcations on specific classes of identified cards. (These MSM characteristics are 

fiirther described in coimection with Figtire 5.) 
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Other data can also be storoi on the card at this time as needed by the 

system design such as an address table or further subroutines. 

Step 311 sets the enablement bit in EEPROM of the card -which indicates 
that the enablement process has been completed for the particular card. When this bit is 
5 set, ano&er enablement process cannot occur on the card. This ensures tiiat only one 
personalization and enablement process wiU occur to the card thus preventing illegal 
tampering of the card or altering the card by mistake. In the preferred embodiment, the 
enablement bit is initially not set when the card is manufactured and is set at the end of 

the enablement process. 
1 0 Figure 4 shows an example of a block diagram of an IC card chip which 

has been manufactured and personalized. The IC card chip is located on an IC card for 
use. The IC card preferably includes a central processing unit 401, a RAM 403, a 
EEPROM 405, a ROM 407, a timer 409, control logic 41 1, an I/O ports 413 and security 
circuitry 415, which are connected together by a conventional data bus. 
15 Control logic 411 in memory cards provides sufficient sequencing and 

switching to handle read-write access to the card's memory through the input/output 
ports. CPU 401 with its control logic can perform calculations, access memory locations, 
modify memory contents, and manage input/output ports. Some cards have a coprocessor 
for tianrflmg complex computations like cryptographic algorithms. Input/output ports 
20 413 are used under the control of a CPU and control logic alone, for communications 

between die card and a card acceptance device. Timer 409 (which generates or provides a 

clock pulse) drives the control logic 41 1 and CPU 401 through the sequence of steps that 
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accomplish memory access, memory reading or wntmg, proccssmg, and data 
communication. A timer may be used to provide application features such as call 
duration. Security circuitry 415 includes fusible links that connect the mput/output lines 
to internal circuitry as required for testing during manufacture, but which are destroyed 
5 CT)lown'0 upon completion of testing to prevent later access. The personalization data to 
qualify the card is stored in a secured location of EEPROM 405. The comparing of the 
personalization data to applications permissions data is performed by the CPU 401. 

Figure 5 shows the steps of generating and loading the four elements of 
the card personalization data into the memory of the IC cards, and Fig. 5 A shows a 
10 schematic of bit maps for each identity field residing in the memory of an IC card 
containing personalization data in accordance with the present invention. Each data 
structure for each identity field has its own descriptor code. Step 501 loads the data 
structure for the identity field •*card ID** called "msm_mcd_permissions_mcd_no.*' This 
nomenclature stands for MULTOS system manager _ MULTOS card device _ 
15 permissions^ MULTOS card device number. Although this number is typically 8 bytes 
long as shown in Fig. 5 A, the data could be any length tiiat indicates a unique number for 
the card. In the preferred embodiment, 2 bytes are dedicated as a signal indicator, 2 bytes 
comprise a MULTOS Injection Security Module ID (MISM ID) indicating which security 
module mjected the card with its injected keys when it was manufactured, and 4 bytes 
20 comprise an Integrated Circuit Card (ICC) serial number which identifies the individual 
card produced at the particular MISM. 
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Step 503 loads the data structure for the identity field "issuer ID" called 
•*msmjcncd_j)ennissions_ mcd_issuer_id." This nomenclature stands for a MULTOS 
card device issuer identification number. Each card issuer (such as a particular bank, 
financial institution or other company involved with an application) will be assigned a 

5 unique number in the card system. Each IC card in the MULTOS system will contain 
information regarding the card issuer which personalized the card or is responsible for the 
card. A card issuer will order a certain number of cards &om a manufacturer and perform 
or have performed the personalization process as described herein. For example, a 
regional bank may order 5,000 cards to be distributed to its customers. The 

10 "mcd_issuer_id'' data structure on these cards will indicate which issuer issued the cards. 
In the preferred embodiment, the data structure is 4 bytes long (as shown in Fig. 5A at 
503 A) to allow for many different issuers in the system although the length of the data 
structure can vary with the needs of the card system. 

Step 505 loads the data structure for the identity field "product ID'* called 

15 "msm_mcd_permissions_mcd_ issuerjproduct^id.** This nomenclature stands for 

MULTOS card device issuer product identification number. Each card issuer may have 
different classes of products or cards which it may want to differentiate. For example, a 
bank could issue a regular credit card with one product ID, a gold credit card with another 
product ID and a platinum card with still another product ID. The card issuer may wish 

20 to load certain applications onto only one class of credit cards. A gold credit card user 

who pays an anmial fee may be entitled to a greater variety of applications than a regular 

credit card xiser who pays no annual fee. The product ID field identifies the card as a 
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particular class and wiU later allow the card issuer to check the product ID and only load 
s^lications onto cards which match the desned class. 

Another way to differentiate products is by application type, such as by 
categorizing the application as financial legal, medical and/or rccreationaU or by 
5 assigning particular applications to a group of cards. For example, one card issuer may 
have differcm ioyahy programs available with different companies to different sets of 
card users. For example, a bank may have an American Airlines® loyalty program and a 
British Airways® loyalty program for different regions of die country dependent on 
where the airlines fly. The product type allows the issuer to fix the product classification 
10 of the card during the personalization process. When loading applications onto the card, 
die product type identification number on each card will be checked to make sure it 
matches the type of card onto which tiie issuer desires to load. The product type data 
strucnire is preferably an indexing mechanism (unlike die other personalization data 
strucmre) of 8 bits (as shown at 505 A in Fig. 5A) but could be any length depending 
15 upon the needs ofthe card system. In the illustrated embodhnent, the resulting 

instmction would be to locate the second bit (since die byte's indicated value is 2) in tiie 
array to be searched (see discussion of step 809 below). 

Step 507 loads the data stracture for the identity field data called 
•^sm_mcd_peimissions_mcd_ controls_data_ date." This nomenclature stands for the 
20 MULTOS card device controls data date or, in otiier words, the date on which die card 
was personalized so that, for example, the application loader can load cards dated only 

after a certain date, load cards before a cenain date (e.g., for application updates) or load 
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cards with a particular data date. The information can include the year, month and day of 
personalization or may include less infbimarion, if desired. The data_date data strucnire 
is preferably 1 byte in length (see 507A in Fig. 5 A) although it could be any length 
depending upon the needs of the particular card system used. 
5 Once all of the personalization data structtires are loaded and stored in the 

card, the card has been identified by issuer, product class, date and identification number 
(and other data fields, if desired), and the card cannot change its identity; these fields 
cannot be changed in the memory of the card. If a card user wants to change the 
productjd stored in the card to gain access to different appUcations available to another 
10 product type, a new card wiU have to be issued to the user containing the correct 

personalization data. This system is consistent with a gold card member receiving a new 
card when the classification is changed to platinum. 

After the card has been enabled and personalized by storing its individual 
card key set, MSM personalization characteristics and enablement bit as described in Fig. 
15 3, the card is ready to have applications loaded into its memory. 

T-nariino Anplieations 
The application loading process contains a number of security and card 
configuration checks to ensure the secure and proper loading of an appfication onto the 
intended IC card. The application loading process is preferably performed at the 
20 personalization bureau so that the card will contain one or more applications when the 
card is issued. The card may contain certain common applications which will be present 

on every card the issuer sends out. such as an electronic purse application or a credit/debit 
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application. Alternatively, the personalizatioii bureau could send the enabled cards to a 
third party for the process of loading applications. The multiple application operating 
system stored in the ROM of each card and the card MSM personalization data is 
designed to allow future loadmg and deleting of appHcations after the card has been 

5 issued depending upon the desires of the particular card user and the responsible card 
issuer. Thus, an older version of an application stored on the IC card could be replaced 
with a new version of the application. An additional loyalty application could also be 
added to the card after it has been initially sent to the card user because the application is 
newly available or the user desires to use the new application. These loading and deleting 

1 0 functions for applications can be perforaied du'ectly by a teraunal or may be performed 
over telephone lines, data lines, a network such as the Internet or any other way of 
transmitting data between two entities. In the present IC card system, the process of 
transmitting the application program and data ensures that only IC cards containing the 
proper personalization data and which fit on application permissions profile will be 

15 qualified and receive the corresponding application program and data. 

Figure 6 shows the preferred steps performed in loading an application 
onto an IC card in the MULTOS IC card system. For this example, the personalization 
bureau is loading an application firom a terminal which enabled the same card. Step 601 
performs an "open command" iiutiated by the terminal which previews the card to make 

20 sure the card is qualified to accept the loading of a specific application. The open 

command provides the card with the application's permissions data, the application's 

size, and instructs the card to determine (1) if the enablement bit is set indicating the card 
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has been personalized; (2) whether the application code and associated data will fit in the 
existing memory space on the card; and (3) whether the personalization data assigned to 
the application to be loaded allows for the loading of the application onto the particular 
card at issue. The open command could also make additional checks as required by the 

5 card systcriL These checking steps during the open command execution will be described 
in detail in conjunction with Figure ?♦ 

After the open command has been executed, the application loader via the 
terminal will be advised if the card contains the proper identification personalization data 
and if enough room exists in the memory of the card for the application code and related 

1 0 data. If there is insufficient memory, then a negative response is returned by the card and 
the process is abended (abnormally ended). If the identification personalization data does 
not match the applications permissions data, a warning response is given in step 603, but 
the process continues to the load and create steps. Alternatively, if there is no match, the 
process may automatically be abended. If a positive response is returned by the card to 

15 the terminal in step 605, the application loader preferably proceeds to next steps. The 
open command allows the application to preview the card before starting any transfer of 
the code and data. 

Step 607 then loads the application code and data onto the IC card into 
EEPROM. The actual loading occurs in conjimction with create step 609 which 

20 completes the loading process and enables the application to execute on the IC card after 
it is loaded. The combination of the open, load and create commands are sent fay the 

terminal, or another application provider source, to the IC card to perform the application 

-51- 



BNSDOCID: <WO 98521 62A2 I > 



SUBSTITUTE SHEET (RULE 26) 



wo 98/52162 



PCT/GB98/01402 



AimEX fl lOMflKOllFIIOH | 

loading process. The operating system in the IC cards is progranuned to perfonn a 
specific set of instructions with respect to each of these cominands so that the IC card will 
conmunicate with and property cany out the instructions from the te rminal . 

Step 609 perfonns the create command which at least: (1) checks if an 
5 appHcation load certificate is signed (encrypted) by the CA and therefiare authenticates 
the application as a proper application for the system; and (2) checks the card 
personalization data stored on the card against the peraiissions profile for the application 
to be loaded to qualify the card for loading. It may do other checks as required. If one of 
the checks fails, then a failure response 610 is given and the process aborts. The 
1 0 application after it has passed these checks will be loaded into the memory of the card. 

Rgure 7 shows the various steps of the open step 601 of Fig. 6 in more 
detail. Step 701 determines if the enablement (i.e., control) bh is set This bit is set when 
the card has completed its personalization process and has been assigned its 
personalization data. An application can be loaded on an IC card in the card system only 
15 if the card contains the personaUzation data. If the enablement bit is not set, the card has 
not been personalized and therefore the card returns a negative response 703 to the 
terminal. If the enablement bit is set, then the card has been enabled and the test 
conditions continue with step 711. 

Step 711 checks if there is sufficient space in the memory on the card to 
20 store the application code and its associated data. Applications will typically have 

associated data related to their functions. This data will be used and manipulated when 

the application is run. Storage space in the memory of an IC card is a continumg concern 
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due to the relatively large physical space required for EEPROM and how it fits in the 
integrated circuit which is desired to be small enough to fit on a credit card sized card. 
An example of the size of a preset EEPROM on an IC card is 16K bytes although the 
actual size varies. AppUcations can range torn IK byte or less for a very simple 
5 appUcation up to the size of available memory for a more sophisticated application. The 
data associated with an ^plication can range firom no data being stored in the card 
memory to a size constrained by the amount of available memory. These varied sizes of 
application code and data continually increase as appUcations become more advanced and 
diverse. 

1 0 MULTOS as an operating system is not limited by the number of 

applications and associated data it can store on the card. Thus, if five appUcations can fit 
in the available memory of the card, the card user will have greatly increased 
functionality than if one or two appUcations were stored on the card. Once a card's 
memory is fiUed to its capacity, however, a new appUcation cannot be loaded onto the 

15 card unless another appUcation including its code and data of sufficient size can be 

deleted. Therefore, checking the amount of available space on the card is an important 
step. If there is not sufficient space, then an insufficient space response 713 wiU be 
returned to the teraiinal. The application loader can then decide if another existuig 
appUcation on the card should be deleted to make room for the new appUcation. Deletion 

20 depends upon the card issuer having an appUcation delete certificate fit)m the CA. If 
there is sufficient space on the card, then the process continues with step 715. 
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An example of the testing of memory spaces in step 711 is now described. 
The numbers used in this example in no way limit the scope of the invention but are used 
only to illustrate memory space requirements. An IC card may have 16K available 
EEPROM when it is first manufactured. The operating system data necessary for the 
5 operating system may take up 2K of memory space. Thus, 14K would remain. An 

electronic purse application's code is stored in EEPROM and may take up 8K of memory 
space. The purse application's required data may take up an additional 4K of memory 
space in EEPROM. The memory space which is free for other applications would thus be 
2K (16K-2K-8K-4K=2K). If a card issuer wants to load a credit/debit appUcation whose 
10 code is 6K bytes in size onto the card in this example, the application will not fit in the 
memory of the IC card. Therefore, the application cannot load the new application 
without first removing the purse application fiom the card. If a new credit/debit 
application was loaded mto EEPROM of the IC card, then it would have to overwrite 
other application's code or data. The application loader is prevented from doing this. 
15 Figure 8 shows the steps performed in determining whether the card's 

personalization data falls within the permissible set of cards onto which the application at 
issue may be loaded. These steps are preferably performed during the execution of the 
"create" command. However, these steps may be performed at any time during the 
loading or deleting of an application. As described previously, the card is personalized 
20 by storing data specific to the card (MSM personalization data) including: a card ID 

designation specific to an individual card, the card issuer number indicating the issuer of 
the card, the product type of the card, such as a gold or platinum card, and the date the 
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card was personalized. This data uniquely identifies the card apart from all other IC cards 
in the system. 

Accordingly, applications can be selectively stored on individual cards in 
the IC card system on virtually any basis, including the following. An application can be 

5 loaded selectively to cards containing one or more specific card numbers. An application 
can be selectively loaded on one or more cards containing a specified card issuer ID. 
Moreover, an application can be loaded only upon one type of product specified by the 
particular card issuer, and/or the application can be loaded only on cards which have a 
specified date or series of dates of personalization. Each of the personalization data 

10 allows an application to be selectively loaded onto certain cards or groups of cards and 
also ensures that cards without the proper permissions will not receive the application. 
Personalization data types in addition to the four described can also be used as needed. 

The selection of IC cards upon which a particular application may be 
loaded is made possible by the use of "applications permissions data" which is assigned 

15 to the application and represents at least one set of cards upon which the application may 
be loaded. The set may be based on virtually any factor, including one or more of the 
following: card numbers, card issuers, product types or personalization dates. Although 
the individual card's personalization data typically identify one specific number, one card 
issuer, one product type and one date, the application's permissions data may indicate a 

20 card numbers or a blanket pemiission, a card issuer or a blanket permission, and a 
number of product types and dates. 
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For example, a frequent loyalty program may be configured to aUow its 
loading and use on cards in different product classes belonging to one card issuer. In 
addition, the appUcation permissions data may indicate that the loyalty program can be 
used on gold and platinum product types if the card was issued after May, 1998. Thus, 
5 the MSM permissions check will determine if the card's individual personalization data is 
included in the allowed or permissible set of cards upon which the appUcation may be 
loaded. If it is, the application will be loaded. 

To expedite the comparison process, an alternative embodiment may 
include setting one or more permissions data at zero representing a blanket permission for 
10 that particular data. For instance, by placing a zero for the "card number" entry in the 
appUcation permissions data or some other value indicating that all cards may be loaded 
regardless of their number, the system knows not to deny any cards based on their card 
number. Moreover, if a zero is placed m the appUcation's permissions data "issuer ID," 
then all cards similarly wiU pass the "issuer" test comparison. This feamre aUows greater 
15 flexibiUty in selecting groups of cards. The zero indicator could also be used for other 
permissions data, as reqiiired. 

Referring to Figure 8, each of the permissions data is checked in the order 
shown, but odier orders could be followed because if any one of the permissions fails, the 
appUcation wiU be prevented from being loaded on the IC card bemg checked. The 
20 permissions are preferably checked in the order shown. Step 801 checks if the 

appUcation permissions product type set encompasses the card's product type number 

stored in the memory of the card. Each card product type is assigned a number by the 
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system operator. The product types are specified for each card issuer because different 
card issuers wiU have different product types. The cards are selectively checked to ensure 
that applications are loaded only on cards of authorized product type. The application 
pennissions product type set can be 32 bytes long which includes multiple acceptable 
5 product types or can be a different length depending upon the needs of the system. Using 
data structure 505A as an example, the operating system would check bit number 2 in the 
256 bh array (32 bytes x 8 bits per byte) resulting fi-om the 32 byte long application 
permissions data structure. If the pemiissions check fails, then the card returns a failure 
message to tiie terminal m step 803. If the product type check passes (for example, die 
10 value of bit no. 2 being 1), then the process continues with step 805. 

Step 805 checks if the application pennissions allowable card issuer 
number set encompasses the card's issuer number stored in the memory of the card or if 
the application pemiissions issuer data is zero (indicating all cards pass tiiis individual 
permissions check). Each card issuer is assigned a mnnber by the system operator and 
15 the cards are selectively checked to ensure that applications are loaded only on cards 

distributed by authorized card issuers. The application permissions card issuer number 
set can be 4 bytes long if one issuer is designated or can be longer depending upon the 
needs of the system. If the issuer check fails, tiien the card returns a failure message to 
the terminal m step 807. If the check passes, tiien the process continues with step 809. 
20 Step 809 checks if the application permissions date set encompasses the 

card's data date stored in the memory of the card. The date that the IC card was 
personalized will be stored and will preferably include at least the month and year. The 
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cards are selectively checked to ensure that appUcations are loaded only on cards with the 
authorized personalization date. The application permissions date set can be 32 bytes 
long which includes multiple dates or can be a different length dcpcndmg upon the needs 
of the system. If the date pemiissions check fails, then the card returns a failure message 
5 to the terminal in step 811. If the date check passes, then the process continues with step 
813. 

Step 813 checks if the application permissions allowable card number set 
encompasses the card's ID number stored in the card memory or if the application 
permissions allowable card number data is zero (indicating all cards pass this individual 

10 pemMSsions check). The testing of the permissions is perforaied on the card during the 
execution of the open, load and create commands. The application pemiissions card 
number data set can be 8 bytes long if one number is designated or can be longer 
depending upon the needs of the system. If the card number check fails, then the card 
returns a failure message to the terminal in step 815, If the check passes, then the process 

15 continues with step 817. 



Summary of TC Card System's Process 

Figure 9 shows the components of the system architecture for the card 

initialization process of an IC card in a secure multiple application IC card system. The 

system includes a card manufacturer 102, a personalization bureau 104, an application 

20 loader 106, the IC card 107 being initialized, the card user 109 and the certification 

authority 111 for the entire multiple application secure system. The card user 131 is the 
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person or entity who will use the stored applications on the IC csrd. For example, a card 
user may prefer an IC card that contains both an electronic purse containing electronic 
cash (such as MONDEX™) and a credit/debit application (such as the MasterCard® 
EMV application) on the same IC card. The following is a description of one way in 
5 which the card user would obtain an IC card containing the desired applications in a 
secure manner. 

The card user would contact a card issuer 113, such as a bank which 

distributes IC cards, and request an IC card with the two apphcations both residmg in 

memory of a single IC card. The integrated circuit chip for the IC card would be 

10 manufactured by manufacturer 102 and sent to the card issuer 1 13 (or an entity acting on 

its behalf) m the form of an IC chip on a card. As discussed above (see steps 201-209), 

during the manufacturing process, data is transmitted 1 15 via a data conduit from the 

manufacturer 102 to card 107 and stored in IC card lOTs memory. (Any of the data 

conduits described in this figure could be a telephone line, Internet connection or any 

15 other transmission medium.) The certification authority 111, which maintains 

encryption/decryption keys for the entire system, transmits 117 security data (i.e., global 

public key) to the manufacturer over a data conduit which is placed on the card by the 

manufacturer along with other data, such as the card enablement key and card identifier. 

The card^s multiple application operating system is also stored in ROM and placed on the 

20 card by the manufacturer. After the cards have been initially processed, they are sent to 

the card issuer for personalization and application loading. 
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The card issuer 1 13 pcrfonns, or has perfonned by another entity, two 
separate functions. First, the personalization bureau 104 personalizes the IC card 107 in 
the ways described above, and second, the application loader 106 loads the application 
provided the card is qualified, as described. 
S Regarding personalization, an individualized card key set is generated by 

the CA and stored on the card (see Fig. 3). The card is further given a specific identity 
using MSM personalization (see Fig. 3, step 307 and Fig. 5) including a card ID number, 
an issuer ID number identifying the card issuer which processed the card, a card product 
type number which is specified by the card issuer and the date upon which the 

10 personalization took place. After the card has been personalized, applications need to be 
loaded onto the card so that the card can perform desired functions. 

The application loader 106, which could use the same terminal or data 
conduit as personalization bureau 104, first needs to have detemiined if the card is 
qualified to accept the application. This comparison process takes place on the card itself 

15 (as instructed by its operating system) using the pemiissions information. The card, if it 
is qualified, thus selectively loads the application onto itself based upon the card's 
identity and the card issuer's instructions. The application loader communicates 119 with 
the IC card via a terminal or by some other data conduit. After the applications have been 
loaded on the card, the card is delivered to the card user 109 for use. 

20 The secure multiple application IC card system described herein allows for 

selective loading and deleting of applications at any point in the life cycle of the IC card 

after the card has been personalized. Thus, a card user could also receive a personalized 
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card with no appUcations and then select a desired appUcation over a common 
transmission line such as a telephone line or Internet connection. 

Figinc 10 is a system diagram of entities involved with the use of an IC 
card once it has been personalized. Tbc system includes an IC card 151. a terminal 153, 
5 an appUcation load/delete entity 155. the certification authority 157. a card issuer 171 and 
other IC cards 159 in the system. ITw arrows indicate communication between the 
respective entities. The CA 157 faciUtates loading and deleting of applications. After 
providing the MSM permissions data and card specific keyset to the card during card 
enablements, the CA allows applications to be later loaded and deleted preferably by 
10 issuing an appUcation certificate. AppUcation specific keys are required to authenticate 
communication between a card and terminal. The IC card 151 also can communicate 
with other IC cards 159. Card issuer 171 is involved with all decisions of loading and 
deleting applications for a card which it issued. All communications are authenticated 
and transmitted securely in the system. 
15 For instance, IC card 151 wiU use the following procedure to load a new 

appUcation onto the card. IC card 101 is connected to terminal 153 and the terminal 
requests that an appUcation be loaded. Termmal 153 contacts application load/delete 
entity 155 which, as a result and in conjunction with card issuer 171, sends the 
appUcation code, data and application permissions dau (along with any other necessary 
20 data) to terminal 153. Teraiinal 153 then queries card 151 to ensure it is the correct card 
onto which the appUcation may be loaded. If IC card passes tiie checks discussed above. 

the application is loaded onto card 151. The CA 157 provides the application load or 
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delete certificate that enables the application to be loaded or deleted from the card. This 
example shows one way to load the appUcation, but other variations using the same 
principles could be performed, such as directly loading the application at the application 
load/delete entity 155. 

5 The foregoing merely iUustrates the priiiciples of the iinrentioiL It will 

thus be appreciated that those skilled in the art will be able to devise numerous systems 
and methods which, although not explicitly shown or described herein, embody the 
principles of the invention and are thus within the spirit and scope of the invention. 

For example, it will be appreciated that the MSM personalization and 
10 permissions data may not only be used for loading applications onto IC cards but also for 
deleting appUcations from said cards. Hie same checks mvolving MSM permissions and 
loading applications are made for deleting appUcations. A delete certificate from the CA 
authorizing the deletion of an application will control from which cards the application 
may be deleted. This is accomplished through the personalization data stored on each IC 
15 card and &e permissions check as described herein. 

Moreover, the data may also be applicable to personal computers or "Other 
units onto which plications may be loaded which are not physically loaded on cards. In 
addition, the application's permissions data may actoally include data representative of a 
set or sets of cards to be excluded, instead of included - cards that cannot be loaded with 
20 the plication. 
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The scope of the present disclosure mcludes any novel feature or combmation 
of features disclosed therein either explicitly or impUcitly or any generalisation thereof 
irrespective of whether or not it relates to the claimed invention or mitigates any or all 
of the problems addressed by the present invention. The appUcant hereby gives notice 
that new claims may be formulated to such features during the prosecution of this 
application or of any such fiirther appUcation derived therefrom. In particular, with 
reference to the appended claims, features from dependent claims n^y be combined 
with those of the independent claims in any appropriate manner and not merely in the 
specific combinations enumerated in the claims. 
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CLAIMS: 

1 1 . An IC card system comprising at least one IC card, an application 

2 to be loaded onto said card and means for determining whether said card is qualified to 

3 accept the loading of said application onto said card. 

1 2. The IC card system of claim 1, wherein said IC card contains card 

2 personalization data, and said application is assigned application permissions data 

3 representing at least one set of IC cards upon which said application may be loaded, 

1 3. The IC card system of claim 2, wherein said detemiining means 

2 compares said card personalization data with said application permissions data, 

1 4. The IC card system of claim 3, wherein whether said application is 

2 loaded onto said IC card depends on the result of said comparison, such that in the event 

3 the card personalization data matches said permissions data set the card is qualified and 

4 the application is loaded. 



5. The IC card system of any of claims 2 to claim 4, wherein said 
personalization data comprises data representative of a unique card identification 
designation. 
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1 6. The IC card system of any of claims 2 to claim 5, wlierein said 

2 personalization data conq)rises data representative of a card issuer. 

1 7. The IC card system of any of claims 2 to claim 6, wherein said 

2 personalization data comprises data representative of a product class. 

1 8. The IC card s\'stem of any of claims 2 to claim 7, wherein said 

2 personalization data comprises data representati\'e of a date. 

1 9. An IC card system comprising at least one IC card and an 

2 application, wherein said IC card contains personalization data representative of that card 

3 and said application is assigned a permissions data set representing at least one IC card 

4 upon which said application may be loaded, said system fiarther comprising means for 

5 determining whether said personalization data falls within said permissions data set. 

1 10. The IC card system of claim 9 wherein said application is loaded 

2 onto said IC card in the event said determining means determines that said 

3 personalization data falls within said set. 



1 

•7 



11. The IC card system of claim 9 or claim 1 0 wherein said personalization 
data comprises data representing a card identification designation, and an issuer of said 
card. 
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^ 12. The IC card system of any of claims 9 to claim 1 1 wherein said 

^ personalization data con^rises data representing a product class and a date. 

^ 13. The IC card system of any of claims 9 to 12 wherein said permissions 

^ data set includes a plurality of card identification designations. 

1 14. The IC card system of any of claims 9 to 13 wherein said permissions 

2 data set includes one or more issuers of IC cards. 

1 15. The IC card system of any of claims 9 to 14 wherein said permissions 

2 data set includes one or more product classes. 

1 16. The IC card system of any of claims 9 to 15 wherein said permissions 

2 data set includes a plurahty range of dates. 



1 
2 



17. The IC card system of any of claims 9 to 16 wherein said permissions 
data set includes all IC cards which attempt to load the apphcation. 



1 18. An IC card system comprising at least one IC card, an application 

2 to be loaded onto said card and means for enabling said card to be loaded with said 

3 application. 
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1 19. The IC card system of claim 18 wherein said enabling means 

2 comprises means for storing personalization data onto said card. 

1 20. The IC card system of claim 1 8 wherein said enabling means 

2 comprises means for setting an enablement bit. 

1 21. The IC card system of claim 19 wherein said enabling means 

2 comprises means for setting an enablement bit. 

1 22, The IC card system of claim 20 further comprising means for 

2 checking the enablement bit prior to enabling said IC card to deteraiine whether or not 

3 said card has already been enabled. 

1 23. The IC card system of claim 21 further comprising means for 

2 checking the enablement bit prior to enabling said IC card to determine whether or not 

3 said card has already been enabled. 

1 24. A process for loading an appUcation onto an IC card comprising 

2 the step of determining whether said IC card is quahfied to accept the loading of said 

3 application onto said card. 
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1 25. The process of claim 24 wherein said deteimining step includes the 

2 steps of: providing said card with personalization data; 

assigning to said appUcation permissions data representing at least 

4 one set of IC cards upon which said application may be loaded; 

5 comparing said personalization data with said permissions data; 

6 and 

loading said appUcation onto said IC card provided said 



srsonalization data falls within said set of cards upon which said application may be 



8 P 

9 loaded. 

1 26. The process of claim 25, wherem said personalization data 

2 comprises data representative of a card identification designation. 



^ 27. The process of claim 25 or claim 26, wherein said personalization data 

comprises data representative of a card issuer. 

^ 28. The process of any of claims 25 to claun 27, wherein said 

^ personalization data comprises data representative of a product class. 

^ 29. Theprocessofany of claims 25 to claim 28. wherein said 

^ personalization data comprises data representative of a date. 

-68- 

SUBSTITUTE SHEET (RULE 26) 

BNSDOCID: <WO . 9852162A2 .1 > 



wo 98/52162 



PCT/GB98/01402 



m 0 wmmm 

1 30. The process of any of claims 25 to claim 29 further comprising the first 

2 step of enabling said card to be loaded with said apphcation. 

1 31. The process of claim 30 wherein said enabling step includes the 

2 step of storing personalization data onto said card. 

1 32. The process of claim 30 wherein said enabling step includes the 

2 step of setting an enablement bit indicating that the card has been enabled. 

1 33. The process of claim 31 wherein said enabling step further includes 

2 the step of setting an enablement bit indicating that the card has been enabled. 

1 34. The process of claim 32 wherein prior to said enabling step a 

2 checking step is performed to determine whether said card has been enabled. 

1 35. The process of claim 33 wherein prior to said enabling step a 

2 checking step is performed to detennine whether said card has been enabled. 

1 36. A process for deleting an application from an IC card comprising 

2 the step of determining whether said IC card is qualified to delete said application based 

3 upon pemiissions data associated with said application. 
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1 37. The process of claim 3 6 wherein said deieraiining step includes the 

2 steps of: 

3 providing said card with personahzation data; 

4 assiening to said application permissions data representing at least 

5 one set of IC cards from which said application may be deleted; 

6 comparing said personalization data with said peraiissions data; 

7 and 

8 deleting said application from said IC card provided said 

9 personalization data falls within said set of cards from which said application may be 
10 deleted. 



1 38. The process of claim 37, wherein said personalization data 

2 comprises data representative of a card ideniification designation. 

1 39. Hie process of claim 37 or claim 38, wherein said personalization data 

2 comprises data representative of a card issuer. 

1 40. The process of any of claims 37 to claim 39, wherein said 

2 personalization data comprises data representative of a product class. 



1 41. The process of any of claims 37 to claim 40, wherein said 

2 personalization data further comprises data representative of a date. 
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1 42. An IC card system comprising at least one IC card, an application 

2 to be deleted from said card and means for detemiining whether said card is qualified to 

3 delete said application from said canL 

1 43. The IC card system of claim 42, wherein said IC card contains card 

2 personalization data, and said application is assigned apphcation permissions data set 

3 representing at least one set of IC cards from which said application may be deleted. 

1 44. The IC card system of claun 43, wherein said detennining means 

2 compares said card personalization data with said application peraiissions data. 

1 45. The IC card system of claim 44, wherein whether said application 

2 is deleted from said IC card depends on the result of said comparison, such that in the 

3 event the card personalization data matches said permissions data set the card is qualified 

4 and the application is deleted. 
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Muhi-Appjit-atinn TC Ca rd System 



A multi-appUcation IC card system is disclosed having selective 
application loading and deleting capabiUty. Prior to loading an application onto an IC 
card a test is conducted to determine if the card is quaUfied to receive the appUcation 
using personaUzation data stored on the card and comparing it with permissions data 
associated with the application indicating one or more sets of cards upon which the 
application may be loaded. If the personalization data of the card falls within the 
allowable set of permissions for that appUcation then the card may be loaded with the 
application. Preferably, the personalization data includes data representative of the card 
number, issuer, a product class and the date on which the card is personalized. 
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WE CLAIM : 

1 1. A multiple application card system comprising: 

2 a certification authority for which a public and private key 

3 pair are generated; 

4 at least one integrated circuit card including at 

5 manufacwre said public key of said certification authority and a card identifier 

6 for uniquely identifying each said card; 

7 means for creating at said certification authority a 

8 personalization data block for at least one card identifier, means for encrypting 

9 said personalization data block and forwarding said encrypted data block to a 

10 personalization bureau; 

1 1 means for loading at said personalization bureau said 

12 encrypted data block on said card having the card identifier matching said 

13 encrypted personalization data block; 

14 means for determining based at least on said encrypted 

15 personalization data block whether one of said integrated circuit cards is 

16 qualified to accept the loading of a specific application; 

17 means for authenticating said application for loading onto 

18 said card by using said public key of said certification authority; and 

19 loading means responsive to said determining and 

20 authenticating means for securely loading said application onto said card. 
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1 2. The system of claim 1. further comprising personalization 

2 means for enabling at least one of said cards at said personalization bureau. 

1 3. The system of claim 1 or claim 2, wherein said at least one 

2 integrated circuit card further comprises memory means for storing an operating 

3 system for instructing said determining means, authentication means and said 

4 loading means. 

1 4. The system of any of claims 1 to 3 wherein said at least one 

2 integrated circuit card further comprises a card enablement key for facilitating 

3 card specific confidentiality. 

1 5. The system of claim 2 or any preceding claim dependent on 

2 claim 2 wherein said personalization means comprises means for compiling a 

3 list of said card identifiers and means for forwarding said list to said authority. 

1 6. The system of any of clarais 1 to claim 5 wherein said 

2 personalization data block comprises card personalization data and an individual 

3 key set. 

1 7. The system of any preceding claim dependent on claim 4 

2 claim 6 further including means for checking whether said card enablement key 

3 has been set, and wherein said means for loading said encrypted data block only 

4 loads said block in the event said enablement key has not been set, and wherein 
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5 said card enablement key is set upon loading said encrypted data block. 

1 8. A multiple application card system comprising: 

2 one or more integrated circuit cards each including at 

3 manufacmre a public key for authenticating the source of any message to it 

4 from an authority holding a corresponding secret key, a card enablement key 

5 for facilitating card specific confidentiality, a card identifier for uniquely 

6 identifying each card, and memory storing an operating system; 

7 personalization means for enabling said card at a 

8 personalization bureau, said personalization means including means for 

9 compiling a list of said card identifiers and means for forwarding said list to 

10 said authority ; 

11 means for creating at said authority a personalization data 

12 block for each card identifier forwarded to said authority, said data block 

13 including card personalization data and an individual key set for each of said 

14 cards; 

15 means for encrypting each of said data blocks and means 

16 for forwarding said encrypted data blocks to said personalization bureau; 

17 means for checking whether said card enablement key has 

18 been set and, if not, for matchmg said card identifiers with said encrypted data 

19 blocks, loading said encrypted data block on its matched corresponding card, 

20 and setting said enablement key; 

21 means for determining whether said card is qualified to 

22 accept the loading of a specific application; checking means for authenticating 
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23 said specific application to be loaded by checking whether said application has 

24 been signed by said authority; and 

25 means responsive to said determining and checking means 

26 for loading said one or more specific applications. 

1 9. A method for loading one or more applications on an 

2 integrated circuit card comprising the steps of: 

3 transmitting security data including a public key of a 

4 certification authority onto an integrated circuit card; 

5 creating at said certification authority a personalization 

6 data block for said card, encrypting said data block and forwarding said 

7 encrypted dato block to a personalization bureau; 

8 loading said encrypted data block onto said card; 

9 determining based at least on said encrypted data block 

10 whether said card is qualified to accept the loading of a specific application; 

authenticating said application for loading onto said card 
12 by using said public key; 

j3 loading said application in the event said card is qualified 

14 and said application is authenticated. 

1 10. A method for deleting one or more applications from an 

2 integrated circuit card comprising the steps of: 

3 transmitting security dato including a public key of a 

4 certification authority onto an integrated curcuit card; 
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creating at said certification authority a personalization 
data block for said card, encrypting said data block and forwarding said 
encrypted data block to a personalization bureau; 

loading said encrypted data block onto said card; 
determining based at least on said encrypted data block 
whether said card is qualified to accept the deleting of a specific application; 

deleting said application in the event said card is 

qualified. 
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